前言

當你是junior時，每次交給你一個任務你大概可以想像要怎麼樣達成目標，對於丟給你的問題，即使不知道要怎麼解，但你也大概有方向知道怎麼樣做是對的。然而世界沒有想像中的美好，隨著seniority的增加，你處理問題scope越來越大，問題越來越複雜，大部分狀況其實是沒有清楚的答案的，更多是也沒有所謂「正確的答案」存在，在這種情況下你要如何做決策？

這篇文章蠻適合給Senior或者Leader來看，特別是當你發現你的工作充滿著未知與不知道怎麼做決策的問題時，可以看看這個演講提供的建議是否對你有幫助。

演講總結

這篇演講的主題是告訴我們如何做困難的決定以達到遠大的目標，特別是那些你沒經驗也毫無概念的任務。

做決定的困難點

為何隨著年齡增長，你處理的問題會越來越趨困難？

• 因為問題本身越來越模糊，並不像junior的任務這麼清楚定義好。
• 要花的時間越來越長，你要完成任務的時間可能從一兩週變成，一兩個月一兩季甚至變成一兩年。
• 下決定的成本越來越高，一旦走錯路可能要改正回來非常的困難。

在這樣複雜模糊與困難的狀況下，我要怎麼知道我做的決策是對的？
講者表示基本上沒救，當下你擁有的資訊不可能讓你知道最後決策是否是正確的。

因此，與其思考怎麼樣做「對的決定」，不如思考怎麼「修正錯誤」。

如何做決定？

講者建議我們可以使用「精益方法（lean approach）」去達成長期與高不確定性的目標。接下來就是要細講這三個部分。

（圖片來源：原演講投影片）

Step 1. 擬定計畫（Form a plan）

1. 寫下問題的描述、限制、與動機

   不同於那些你已知或熟悉的任務，這種計畫很難擬定就是因為你根本也沒有經驗，所以首要之事就是先釐清問題本身與記錄下來，因為它已經超過你腦袋的記憶體容量了。

2. 指定負責人（DRI，Directly Responsible Individuals）

   通常在做困難決定時都會一群人一起討論，大家會彼此爭論觀點，也因此很容易就會形成爭論半天但毫無結果的狀況，所以這時候這位DRI的目標就是確認整個決策過程是有在向前進邁進的。

3. 打擊分析癱瘓（analysis paralysis）

   跟上一點雷同，基本上就是要防止無進度的討論。在做決策時人常常過度分析事情本身而苦於做出決定。所以嘗試跳脫這個循環，確認每次meeting都是有在向前進的。

而我們希望在擬定計畫的部份能獲得以下成果：

• 以文件記錄下來問題的所有相關資訊
• 確認負責人是誰
• 達成共識選擇一個方向向前邁進

這裡的方向不用是確定的解法（其實你也無法得知確定解法），只要是一個可以嘗試的小賭注就可以，下面來解釋這點。

Step 2. 做小賭注（Place small bets）

小賭注的特徵：

1. 盡量簡單與越小越好
2. 一個月內可以獲得feedback
3. Bonus: 可以平行操作的話更好

做小賭注的目的很明顯，我們希望多樣性的嘗試不同的方向（diversification），利用類似MVP（Minimum viable product）的方式去理解哪個方向比較適合。如此一來我們便可以

1. 獲得更多資訊幫我們做決策
2. 幫助我們思考風險
3. 降低處理問題的複雜度。

這邊有幾個常見的方式是這種小賭注的實現方式

• 可行走的骨架（walking skeletons）：其實就是MVP或者說可以動的prototyping XD。
• 部分上線（Partial releases）：釋出一小部分的功能，利用feature toggle或whitelist控制會受到影響的用戶。

Step 3. 吸取教訓（Get feedback）

最後吸取教訓的部份就是從一次又一次的小賭注中，嘗試做到

• 獲得feedback確認方向是否正確
• 嘗試早點修正與解決問題

總結

當初美國在擬定「登月計畫（Project Moonshot）」的時候，沒有人知道到底該怎麼做，更不知道怎麼做才對。但為了快速達到這個目標，前人做的嘗試就是不斷的利用MVP去嘗試：嘗試發射火箭到太空，嘗試回收火箭，嘗試在太空生存...。不斷的利用快速的feedback loop去逼近目標。

如果大家有興趣可以看看google的X company，他們把各項登月計畫變成一次又一次的登屋頂計畫（roofshots），也才能不斷的達成各種不可能。

最後總結整個演講的點

• 建立一套迭代進步的流程
• 審慎思考，但偏向著重目標（bias toward action）
• 建立護欄，早日發現問題與修正它
• 從小賭注中重新調整與協調
• 不需要等到你真的知道怎麼做之後再開始

個人心得

這篇的主題真的意外的蠻有趣的。

雖然他在講的是做決策，但其實跟解決問題是同樣的道理。一般人可能都會想說解決問題的方法是：先列出你想達成的目標，然後想辦法分成小階段去完成這個目標。但現實狀況是你可能根本對於問題本身都不夠清楚，也沒有前人的經驗，那在這種資訊不完全的狀況下你要怎麼達成你的終極目標。

超越工作本身的哲學

我自己覺得這個approach其實不只是套用在工程上，也是一種很好的生活哲學。

工作的目的其實就是在教導你如何面對世界。

你怎麼處理工作上的未知，其實就跟你怎麼處理生活上的未知是很一樣的道理。工作模式的抽象，其實完全是可以套用在生活上的。

例如你工作覺得無趣而想嘗試轉領域當工程師看看，但你知道這個成本很高，不確定該如何做決定好？那你或許可以套用上述的方法，加入個bootcamp認真花個一兩個月學個coding感受一下，或許可以有更多資訊幫助你做最終決定。

再例如我自己也曾經嘗試改進我的時間管理，而時間管理有各種framework可以套用那我應該選擇哪個呢？我也不知道，所以我就先亂選了Get Things Done（GTD）試試看。在密集的嘗試一個月之後，我發現幾件事：

1. 我不適合GTD。主要是因為中間的review process花的時間有點多，我有點難建立這個習慣。
2. 我內心或許也沒把時間管理當成first priority，動機不夠高，所以我願意投下去的時間精力沒有想像中的高，我想這也是某個會失敗的原因。

就像這個鐵人賽也是一個對自己的嘗試，看看寫文章是不是個適合我的路線XD，目前已經寫了2/3，流程上的收穫蠻多，希望我最後一天有時間好好整理這些東西。

關於如何做決策

當Leader常常發生的事情是，當大家遇到兩難、難以下決定的狀況時，常常會請Leader來決定到底要怎麼做比較好，但其實很多問題Leader本身也不太知道答案。例如說兩個性質相近的API到底要合成一隻還是分成不同的？例如這個DB要使用Mysql還是用HBase？例如我們到底該不該把commit code gen出來的code還是只在deploy的時候dynamic的gen出來？

其實這些大方向決策的問題，我也都沒答案，其實也無法得知哪個比較好。因為**「系統設計本來就是一項預測未來的過程」**。好的設計只是這個設計對於預測的未來剛好比較match，而不好的設計或設計錯誤，往往只是當初的預測跟未來走向不同而已。

所以很多時候與其花時間討論哪個決策是最好的，不如就選擇一個方向做下去，因為計畫總是趕不上變化的。我們自己到最後決策的重點，往往考慮的是當這個決策是錯誤時，有沒有辦法修正？或者這個決策的風險有多高？只要這些小賭注的後果是自己可以承擔的，那我們就可以先往這些方向前進。

所有決策都是最好的決策

不要追求最好的決策，將你的決策變成最好。

雖然與上文寫的沒有什麼關係，但我覺得人生其實就是一連串的決策過程。很多時候你不見得需要像上面那樣做各種小的嘗試，更多時候是快速做決策後，嘗試把下定決心的結果變成最好。

心思細膩的人往往會多想到底哪個決策是最好的？花了很多時間分析優劣，但是卻遲遲不願意下決定。我自己其實也是這樣的人：在考慮要不要換手機前就會思考各種換手機的優劣，在出去玩就會各種比較哪個地方會玩的比較盡興，租房子的時候有兩個各有優劣的選項苦苦無法選擇，究竟要待在現在公司還是換去其他地方，到底應該要跟喜歡的人告白還是不要(?)。花了很多的時間分析優劣卻還是不知道怎麼下決定。

我覺得分析是必要的，但是過度分析只會導致更加難以抉擇，因為其實大部分選擇的優劣，都是無法比較的。所以與其繼續苦惱無法做決定，還不如選定一個方向做下去，然後慢慢的把你的決策調整成最好。但要記住的是這裡的最好不是指如預期結果的最好，而是你自己能接受的最好。因為我們無法控制外界事務，但是我們可以控制自己面對事物的心態。